After learning some Ruby on Rails from the O'Reilly-Net tutorial, I went over the Perl.com Catalyst Tutorial. Then I decided that I'll write an application in it in order to learn it better.
So I began to write it. It took me two or three days and right now I only have a record display page, an edit form and an addition form for one of the tables. Part of it is because I'm not very familiar with Class::DBI and other technologies Catalyst is making use of. Hopefully I'll become more familiar with everything as I invest more time.
Meanwhile, I discovered a misbehaviour in the Catalyst core: trailing slashes
in the PATH_INFO are ignored. So /myapp/path1/ would be reported the
same as /myapp/path1. This may break a lot of relative URLs.
I traced the problem to a line containing
split /\//, $c->req->path, which throws away components
that are empty from the end. A Patch I wrote to change it to
split /\//, $c->req->path, -1 was
rejected after I was told some people may depend on this erroneous
behaviour.
I was instructed to write a Plugin instead, which I did. A problem I encountered was that this call to split appeared right at the beginning of a much larger function. I wrote another patch, to extract a method with this, but it was rejected because they did not want to clutter the API.
Thus, Catalyst-Plugin-SanitizeUrl has to duplicate the code of the function, extract a method out of it, and then override this method. <sigh /> But it works([tm]).
I'm curious how find it compares to the more established CGI::Application MVC framework.
It's now about turn 5 years old and features over a dozen plugins. (disclaimer: I contribute to CGI::App).
Re:contrast to CGI::Application
Shlomi Fish on 2005-06-12T20:26:04
I don't know how easy to use is Catalyst supposed to be, but it's certainly quite complex and gives one a lot of functionality. Add to that the fact that I did not yet read all of the documentation, and it may indicate why it takes me so much time to get the hang of it.
I have worked with CGI::Application in the past. It may be a little stretch calling CGI::App a true MVC framework, especially considering the fact that it's not really RDBMS-aware. In any case, CGI::App is nice and all, but Catalyst gives you much more than CGI::App does.
Re:contrast to CGI::Application
markjugg on 2005-06-17T02:43:00
It may be a little stretch calling CGI::App a true MVC framework, especially considering the fact that it's not really RDBMS-aware.I'm not sure when RDBMS became part of the MVC definition, but it's very easy to add database integration:
package My::Class;
use base CGI::Application';
use CGI::Application::Plugin::DBI (qw/dbh dbh_config/);If you want to use Class::DBI, you can use it normally. CGI::App doesn't need to get the middle.
In any case, CGI::App is nice and all, but Catalyst gives you much more than CGI::App does.
What's one example?
Re:contrast to CGI::Application
Shlomi Fish on 2005-06-18T21:12:56
Well, Catalyst implements caching very well. It has a built-in way to map URLs to methods and parameters, and it also has a much larger number of Plugins than CGI::App has. And there's still a lot to be done in it.
Furthermore, I think it's they who should provide a plugin to get back the old, buggy behaviour, after it's been fixed, for those people (if they even exist) silly enough to depend on these bugs, and not you wanting to get it to behave correctly. Surely it must be a lot easier to do, too, as throwing away trailing slashes is easy; getting them back when they're thrown away first, isn't.
Re:You have my sympathy
Shlomi Fish on 2005-06-18T21:17:21
Thanks for the support. I believe the solution of the Catalyst guys was that I should always use absolute URLs (such starting with a "/"). I personally don't buy that it's a good solution.
